1. Field of the Invention
The present invention relates generally to an improved data processing system and in particular to a computer implemented method and apparatus for testing a database. Still more particularly, the present invention relates to a computer implemented method, apparatus, and computer usable program code for simulating an environment with transactions to test a database.
2. Description of the Related Art
Software applications often interact with each other in a transactional manner. Some software applications request information, others supply information, and other software applications perform both functions while participating in such electronic transactions. Behind most electronic transactions are systems to store, retrieve, process, and manage information used in such transactions. Such systems are commonly known as databases. A database may be a simple organization of small amount of information, or may involve extremely large, complex, interrelated, and interdependent sets of information.
As the size and complexity of a database grows, the reliability and performance of the database become key issues. A database may perform reliably on a small scale, supporting a relatively small number of electronic transactions. Subjecting the database to a large volume of transactions, however, may cause the database to perform inadequately, unreliably, sluggishly, or breakdown altogether. The same may happen when the volume of transaction remains unchanged but the size of the information stored grows or when transactions require more intense processing to complete.
To test for and identify potential reliability and performance issues with a database, administrators and other users set up simulated environments in which they can subject a database to various levels of workloads. Such simulations are important in order to identify potential problem scenarios with respect to a subject database under testing. For example, a specific simulated environment might be set up to test if a database system will adequately support 10,000 Web transactions per minute requesting item descriptions of items in an online catalog, or if the database can simultaneously handle 200 users or applications connecting to it for a variety of processing intensive jobs.
Manufacturers of databases, administrators, users, and third party suppliers have created tools and techniques to test for potential reliability and performance problems with databases. Current simulation techniques have costs associated with them in terms of the amount of time, effort, and expense required to set up adequate simulations. The amount of human resources with the specialized skills required to obtain meaningful results from the simulation make these simulations cost prohibitive in many circumstances. In addition, concerns are present about the number and complexity of different components required to setup each simulation scenario.
Moreover, currently available tools and techniques rely upon compartmentalization of test scenarios, and mass-replication of smaller segments of each scenario. As a result, simulations resulting from such tools and techniques are sensitive to the narrow context of the segments of the specific scenario simulated.
For example, a simulation might be limited only to testing the load handling capabilities of the database when subjected to Web-transactions requesting item details of items in an online catalog. Such a simulation is reflective of the database's true performance because this type of simulation does not include the simultaneous activities of several other applications and users who may be connected to the database for completely unrelated transactions.
As a result, the simulation is not reflective of the database's true performance when only a few of the Web transactions are requesting item descriptions, and several others are either placing orders, making payments, or changing customer profiles. The simulation is sensitive only to the context of responding to a large number of item description requests over the Web. The simulation results are then meaningful only for that limited scenario.
Additionally, setting up even these context-sensitive, simulations requires complex software programming, or code development which in itself poses a host of obstacles that are commonly associated with any software development project. In summary, specialized skills, time to develop, test, and debug the code are required, only then the true object of the simulation can begin.
These types of limited scope simulations are often not sufficient in many situations. The cost and complexity of simulation testing increase exponentially because simply cloning sufficient numbers of limited-scope, context-sensitive, smaller simulations blindly is not practical. Also, this technique does not work because repeating the same transaction, for example, deleting a customer record, would not actually work after the first time the database processes the transaction and deletes the customer record. Relevant variation is needed in each of these numerous clone simulations to get meaningful results from the larger simulation.
Currently, this variation is accomplished through code specially written for this purpose, and is a very tedious and labor-intensive endeavor. Thus presently available tools and techniques address this problem of simulating database workloads using custom code, labor, and resource intensive test environments.